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Abstract 


TempleOS is a unique operating system created by Terry A. Davis, designed to be a modern-day 
homage to the biblical Temple of Solomon. This thesis delves into the technical architecture, 
development environment, and underlying philosophy of TempleOS. It explores the operating 
system's innovative features, including its 64-bit programming environment, single-user design, 
and distinctive graphical interface. By examining the unconventional choices and constraints 
set by Davis, such as the 640x480 resolution and 16-bit color display, the thesis highlights how 
these decisions reflect his vision and the system's intended purpose. Furthermore, the analysis 
considers the cultural and historical context of TempleOS, its reception in the tech community, 
and its significance as an artifact of individual creativity in software development. Through this 
analysis, the thesis aims to provide a deeper understanding of TempleOS, both as a technical 
achievement and a manifestation of personal expression. 
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1 Introduction 


TempleOS is an open source operating system developed by Terry. A. Davis, who developed 
each component of the operating system independently and from scratch, during a decade of 
system development. TempleOS is a 64-bit, multi-core, non-preemptive recreational 
programming operating system that operates at the zero-ring level, with identically mapped 
memory addresses. 


Simplicity is the goal of the operating system, which makes it easy to use and at the same time 
fast. In just 116,007 lines of code, there is an operating system, a kernel, a 64-bit compiler, 
graphics libraries, a programming language, and a bootloader. 


The system is based on a 64-bit monolithic kernel and provides a high level of performance and 
direct access to hardware. Key components include a command interpreter (Shell), a specific 
RedSea file system, a unique DolDoc document type, and a HolyC programming language that 
allows direct manipulation of hardware and memory. 


TempleOS uses specific processes for multitasking and efficient memory management methods, 
such as hash tables and optimized I/O operations. 


In further chapters, a more detailed consideration of the operating system follows, from its 
history to the operating system itself and its components, how certain system components work, 
what makes this operating system unique and what innovations within this operating system 
could be transferred to modern operating systems. 


I.1 History and context 


TempleOS, formerly known as J Operating System, LoseThos and SparrowOS, is an educational 
operating system designed to represent the Temple of Solomon in the Bible. It was created by 
Terry A. Davis (Terry A. Davis), who developed the operating system during the decade after, 
in his words, he had an epiphany. Another motive of Davis was to create a standardized operating 
system intended for everyone that would be updated every 7 years, in his words "a modernized 
Commodore 64". 


Terry Davis (15/12/1969 — 11/08/2018) was an American electrical engineer and programmer 
best known for creating TempleOS, whose development was extremely complex, time- 
consuming and unpredictable for one person. As a teenager, Davis learned assembly language 
on a Commodore 64. He later earned a bachelor's degree in computer engineering from the 
University of Arizona in 1992 and also a master's degree in electrical engineering in 1994. He 
started his career at Ticketmaster in 1990, where he programmed VA X machines as an intern, 
where he gained very important knowledge that played a key role in the development of 
TempleOS, and in 1994 he transferred to the hardware department, where he stayed until 1996. 
From 1996, he started having manic episodes, and was soon diagnosed with bipolar disorder. 
He was later diagnosed with schizophrenia[7 ]. 


Figure I. Terry Davis 


It is not known exactly when the development of TempleOS started, except that in 2005 it was 
known as J Operating System, and in 2006 it changed its name to LoseThos. Davis spreads 
awareness of his system by participating in various online discussions, opening a Reddit account 
in 2008, a Twitter (today's X) account in 2010, Facebook and Stack Overflow in 2011. 


LoseThos changes its name to SparrowOS in 2012, and in October 2012, the first version of 
SparrowOS is also released. March 2013 SparrowOS changes its name to TempleOS, the last 
and de facto final version of which was released in 2014. 


The period from 2016 to the end of 2017 is particularly difficult for Davis, due to his 
increasingly frequent attacks. Davis was hit by a train in August 2018, resulting in his death. 


Figure 2. TempleOS logo 


2 TempleOS 


The following chapters will go through the technical capabilities and features of the TempleOS 
operating system. 


3 Architecture 


When we talk about the architecture of an operating system, we are talking about four main 
components: hardware, kernel, shell, and application. TempleOS is a monolithic architecture 
type, which means that each component of the operating system is located in the kernel, that is, 
it functions in the kernel space, and the components of the operating system communicate with 
each other using calls. Other operating systems that work on the same principle are OS/360, 
VMX, Linux. 


The main advantage of this architecture is that the operating system provides scheduling, 
memory management, and more through system calls. 


The main disadvantage of this architecture is that all components are interdependent and if one 
fails, the whole system fails. Fortunately, TempleOS has an incredibly fast boot time of just one 
to two seconds. In case the user wants to add new functionality to the system, the entire system 
must be changed. 


Features of TempleOS are: 


e A 64-bit operating system that runs exclusively on ring zero, uses single-address 
mapping, and supports multitasking and multiprocessing, 


e 64-bit compiler/assembler for HolyC, no interpretation, JIT and AOT compilation, 64- 
bit pointers, 


e Support for FAT32 and RedSea file systems with compression for hard drives, support 
for RedSea file system for CD/DVD 


e Free, public-domain and open source[1 ]. 


When an operating system is 64-bit, it means that it supports 64-bit instructions. A 64-bit register 
can theoretically reference 16 exabytes of memory. What matters is that a 64-bit computer can 
access more than 4 gigabytes of RAM. A computer with 8 gigabytes has a 64-bit processor, 
otherwise at least 4 gigabytes of memory will be inaccessible to the processor. 


The main difference between a 32-bit and a 64-bit processor is the number of calculations per 
second that they can perform, which affects how quickly tasks can be performed. A 64-bit 
operating system requires a 64-bit processor, can access more memory for better performance, 
uses a 64-bit address space, handles multiple processes better at the same time, and has better 
support for virtualization. 


TempleOS only runs on the zero ring, unlike other systems like Windows or Linux, which means 
that everything that happens happens at the kernel level, including user programs. The user has 
full control over the source code of the operating system and the hardware. It's not practically 
the safest practice, but it'S because, according to Davis, it's fun. The following figure shows a 
pictorial representation of security rings in operating systems (Figure 3). 
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Least privileged 


Most privileged 


Figure 3. Ring of Privilege 


TempleOS is a non-preemptive operating system, which is a type of scheduling where a running 
process can run until it voluntarily gives up control to the scheduler. This is in contrast to 
preemptive scheduling, where the operating system can forcibly terminate a process and allow 
another process to start. 


Address mapping in operating systems refers to the process of translating a virtual address used 
by a program into physical addresses in computer memory. This is a vital feature for operating 
systems that support multitasking and memory protection. 


TempleOS uses a simple "flat" memory model. This means that both the operating system and 
user programs run in the same address space. There is no difference between user space and 
kernel space, which simplifies the architecture but at the cost of less security. TempleOS has no 
virtual memory. All programs and the operating system use physical memory addresses, and 
since there is no virtual memory, the address mapping is direct; the address used by the program 
is the address located in memory. TempleOS includes a memory allocator, but it operates in 
physical memory space. Paging is almost never used. 


This approach enables the simplicity and performance of the operating system, at the cost of 
security and stability. However, DOS and 8-bit home computers of the 1980s operated normally 
without memory protection, and most embedded computers in the world operate without 
protection. The lack of protection enhances the simplicity of the operating system, which is the 
point of TempleOS. 


With other operating systems, one language is used for command line scripts (bash, sh, csh, 
tcsh..) and another for programming. On TempleOS, the command line links directly to the 
HolyC compiler, line by line, and places the code into the memory reserved by Malloc(). 


During booting, many files are compiled before the command line is even accessed. All 
operating system headers are compiled and usable without needing to be included. Everything 
is compiled into native 64-bit machine code, nothing is interpreted and there is no bytecode. 


There is no main() function, instead, names are given to functions that would otherwise be 
main() functions, and they are called by specifying a statement in the global scope. 


3.1 Shell 


It was previously mentioned that TempleOS has its own programming language, HolyC. The 
entire operating system is written in it, except for x64 assembler at lower levels. The same 
language was also used for the shell. 


Every file printed in the shell is a hyperlink. A context menu can be obtained by right-clicking 
on the link (Figure 4). 
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Figure 4. Context menu 


It is possible to use the shell as a REPL (read-eval-print loop) and thus create entire programs 
within the shell. There is a menu file in the home directory that can be accessed by pressing 
Ctrl+M. By modifying this file, a "launcher" can be created as desired. 


Autocomplete is an integral part of TempleOS and is implemented at the system level. The entire 
source code is indexed and each function can be "jumped" anywhere, even from the shell. This 
system works on the same principle in every program within the operating system. 
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One interesting thing is that TempleOS can disassemble a function by calling Uf('Foo'), and 
each printed symbol becomes a hyperlink in a shell window, and clicking on one leads to the 
source, something objdump in Linux cannot do. 


The Type() function can display files, something similar to Unix’s cat. Of course, with the 
presence of hypertext. With this function, bitmaps can also be displayed within the shell itself 
(Figure 5). 


C:7Home >Tupe(" Testi. dd.2"> 

^Sue iza jedinice se racuna da je iza crteza. Jedinica je numericka 
vrednost dodeljena crtezu. Brisanjem broja brise se i crtez asociran 
8? ?egiiSás ans-0x00008881- 1 
Ci7Home>Dir ; 

Iz 

68/13 1% 698 
8871 F eo 
88 P eG 
6s 18: 5n 
86721 H 41 
61716 23> 13 
88714 19:1 a208 
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enr 


Figure 5. Bitmap display inside the shell 


This begs the question for other operating systems - why do shells have to be text only? Why 
can't there be multimedia shells? 


3.2 File Explorer 


Almost all systems have something like a file browser that allows you to search a directory tree 
with a simple click. TempleOS has a File Manager, which is launched by Ctrl+D, but it's 
essentially just an extension ofthe shell, and it's unnecessary. By using hyperlinks, the shell acts 
like a browser. By using the command Dir; for listing it is possible to click on any din oiory 
hyperlink and get a new listing, within the same shell, and by clicking on ".." we can "climb" 
up the tree. The following i migo shows the oe of the File ies (Figure 6). 


Figure 6. File Manager 
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A more practical way through the Dir command; described above is shown in the next picture 


(Figure 7). 
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- an alternative approach 


Figure 7. File Manager 


DolDoc 


3.9 


The most notable feature of TempleOS is its ubiquitous hypertext system, DolDoc. This is the 


basis for both the shell and the text editor. Unlike UNIX, which presents everything in plain 
text, everything in TempleOS is stored in DolDoc format. The format is somewhat similar to 


RTF, and by pressing CTRL+T at any time we can preview the raw text directly[5]. 


In addition to text, DolDoc can store images directly into documents. Macros can be inserted: 
hyperlinked commands that are executed by clicking on them. HTML, JSON, XML, shell 


scripts, source files, text files 


TempleOS replaces all of these with the unique DolDoc. 


"file types" hyperlink. Unlike HTML where clicking on 


For example, in a file there should be a 


that link takes you to a new page that lists file types, here the DolDoc macro is used so that grep 


is run when that link is clicked, making the search always up-to-date (Figure 8). 
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Figure 8. DolDoc format 


By clicking CTRL+R, we open the resource editor, which enables drawing. Everything that is 
drawn is embedded in the document and can be referenced using numbered tags. There is no 
drawing program, instead a new document is opened, drawn in, and saved (Figure 9). 


a da je iza crteza. Jedinica je numericka 


racu . i 
ezu. risanjem broja brise se i crtez asociran 


‘DolDoc test primer ~ 


Figure 9. Working with DolDoc format 


Not every IDE allows you to import images and diagrams directly into source code.. And those 
diagrams are hyperlinked, meaning they can be clicked to go directly to the source code that 
implements them. This is something that modern development environments can pay attention 
to. 


3.4 HolyC 


HolyC is an extended version of the C language in TempleOS, designed by Terry Davis, and as 
such is something between C and C++. What makes it different from C or C++ is that there is 
no main() function. Anything written inside the top-level scope is executed as it passes through 
the compiler. The code is compiled on demand by JIT compiling, so that the program can be run 
without first compiling it using the Zinclude statement inside the command line (Figures 10, 11 
and 12). 


B:7>#include "Funkcija.HCc" Ta lI—— 
David 

6.666667s _ — nee 7 
B:7>FunkcijacC"Funkcija ubacena u memoriju i radi."); 
Davidovs 2 E 

et FF FES ubacena u memoriju i radi. 

6.6666 s 

B:7>Funkcijac"Test"); 

Test 

6.666668s 

Bs:^om 


Figure 12. Loading a function into memory and running it 


Functions can be marked with the Zhelp index compiler directive and thus automatically added 
to the documentation, by dynamic updating, without the need to recompile the entire system. 
HolyC also supports the Zexe directive, which can be used to execute external functions and 
include their output in source code. 


The special lastclass keyword is used as the default argument for functions and enables metadata 
searches by supplying the type name of the previous argument as a string to the compiler. 


There is no predefined linker or object files within TempleOS. Instead, the dynamic linker links 
the symbols at load time, and the symbol table remains available at runtime. 


The class system in HolyC implements full support for metadata and reflection. This means that 
if we take a class, we can enumerate each instance to get its name, offset, etc. Also, it is possible 
to modify any of the metadata of any instance at compile time. Examples of this could be default 
value, min/max range, custom printf format...something that would be interesting to see in 
modern programming languages. 


4  Filesystem 


RedSea is a simple 64-bit file system similar to Windows' FAT32, but instead of clusters, it has 
absolute block addresses, 64-byte directory entries, and no FAT table, only an allocator bitmap. 
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4.1 Bitmap 


The allocator bitmap is one of the free space management techniques in operating systems and 
is a critical aspect of them as it involves the management of free space on the hard disk or other 
secondary storage devices. 


Bitmap or a bit vector is an array or collection of bits where each bit corresponds to one block 
on the disk. The bit can take two values, 0 and 1, where zero indicates that the block is free, and 
one indicates that the block is allocated. The following figure (Figure 13) gives an instance of 
blocks that can be represented using a 16-bit bitmap as: 1111000111111001. 


Block1 |Block2 Block3 


Block4| Block5| Block6 
Block7| |Block8| |Block9 
Block10 Block11 Block12 


Block13 Block14 Block15 


Block16 


Figure 13. Bitmapping example - disk blocks 


The advantage of this technique is that it is simple to understand and that finding the first free 
block is efficient. It requires a word scan (a group of 8 bits) in the bitmap to find a non-zero 
word (a zero word contains zeros in all bits). The first free block is then found by scanning the 
first one (1) bit in the non-zero word. 


A cluster is just a 512-byte sector. Files in TempleOS are stored in contiguous blocks, and cannot 
grow in size. 
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4.2 RedSea file system 
The "CDirEntry" class representing a directory entry is defined as: 


#define CDIR FILENAME LEN38 

public class CDirEntry//64-byte fixed-size 
{ 
Ul6attr; //SeeRS ATTR DIR. I would like to change these. 
U8forCDIR_FILENAME LEN]; //Seechar bmp filename, FileNameChk 
I64ear (blk) //One sector per cluster. 

I64size; //In bytes 
CDatedatetime; //SeeDateTime, Implementation of DateTime 

) 

It contains a 16-bit unsigned integer for the attributes related to the directory, an 8-bit unsigned 
integer for the name, the length of which is defined by CDIR FILENAME LEN, a 64-bit signed 
integer for indicating the cluster (block) number, i.e. the starting location of the file or directory 
on disk, a 64-bit signed integer to define the size of the file in bytes, and a CDate type responsible 
for storing date and time information for the given class. CDate is a special class that handles 
time and date related data. 


H 


The "CRedSeaBoot" class is designed to represent the boot sector of the RedSea file system, 
which is represented as FAT32 in the partition table for BIOS compatibility: 


public class CRedSeaBoot//RedSea is type FAT32 in partition table to fool 
BIOS. 

{ 

U8jump_and_nop[3]; 

U8signature,reserved[4]; //MBR PT REDSEA-0x88. Distinguish from real 
FAT32. 

I64drv offset; //For CD/DVD image copy. 

I64sects; 

I64root clus; (root blk) 

I64bitmap sects; 

I64unique id; 

U8code[462]; 

Ul6signature2; //0xAA55 

un 
It contains information such as jump instructions, signatures, disk offsets, and the actual boot 
code that runs the bootloader when booting the computer from the RedSea partition. The 
Signature attribute contains a value that differentiates it from a real FAT32 file system. The 
signature2 attribute contains a signature indicating that the sector contains valid boot code. This 


is used by the BIOS to recognize the bootable disk. 


Compressed files within the RedSea file system have names ending in Z. 


In addition to RedSea, TempleOS also supports the FAT32 file system, as well as the ISO9660 
file system for CD/DVD drive support. 


The RedSea file system has no bad block table and no redundant allocation table. 


The Commodore 64 had a technique where disk blocks would be linked together by a block 
pointer at the end of each block, which is much worse than having a FAT table like FAT32. 
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RedSea does not allow files to grow because it only has an allocation bitmap and not a FAT 
table. This "flaw" is intentional, as Davis' idea was to create a "modernized Commodore 64". 
When dealing with large, entire files, the fragmentation problem appears, but not for allocations 
in the sub-one megabyte range (with occasional larger allocations). 


It is possible to read a block with an offset from the beginning of the file, and since all files are 
contiguous, this is extremely efficient. It is possible to create entire partitions that can be used 
for a database or to invent a file system using "BlkRead()" and "BlkWrite()" directly on disk. 


This file system captures the spirit of TempleOS with its simplicity and speed, since continuity 
is the fastest. 


Within TempleOS, by entering the command Dir(**", TRUE); a list of files in the current 
directory is obtained with the number of the block in which they are located (Figure 14). 


Figure 14. Display of clusters of listed files 


Using the DClus(<block number») method, a view of the directory with 64-byte items is 
obtained (Figure 15). 
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Figure 15. Directory obtained by block dump 


It is important not to overload the RedSea file system. It is designed so that the drive it is on 


cannot have more than 100 megabytes of files. If too many files (we're talking thousands, 


although the real number is much higher) are on the disk, TempleOS's file manager will spend 


too much time starting itself due to creating a list of everything that exists at boot time. 


Multimedia and audio is practically forbidden because interacting with some of such large files 


will cause memory fragmentation and the system will become practically non-functional. In the 


words of Davis, "we need to function like a kayak, not like the Titanic." 


4 


1 


S Processes and multitasking 


In the TempleOS operating system, there is no distinction between a task, a process or a thread, 
so it was Davis's decision to call them tasks, but for better understanding in the thesis we will 
refer to them as processes. The fs segment register of the processor points at all times to the 
current process. There can only be one window per process, and only processes on the first core 
(Core0) can have windows. Each process contains code and a heap so that memory is reclaimed 
when the process is terminated. Each process has its own hash table of symbols. 


Since all processes have the same address map, it would be correct to call TempleOS "multi- 
thread/single-process". By starting a process on the first core, it is possible to create threads on 
the same core or on other cores. If multiple processes are started, one process will have to wait 
until the other completes. 


5.1 Adam and Seth processes 


Adam process is the parent of all processes and as such is indestructible. It is created at system 
startup and is located in a small window at the top of the screen (Figure 16). 


nsReg::8 
ejnsteg;:8 
rBoot ime: @.955s 
m 
TempleOS US.8038 68713724 18:39:46 


EOF 


Figure 16. main process Adam 


Since the Adam process is non-destructible, its heap is used for all memory objects that need to 
be destroyed. When Adam is created, it starts the ::/StartOS.HC file. When the system startup is 
complete, the Adam process enters server mode where it accepts requests from other processes. 


Each processor core contains an executable process called Seth which is indestructible. The 
Adam process on the first core is also itself a Seth process. 


To monitor processes, the TempleOS equivalent of the ps command is TaskRep() (Figure 17). 


€:7Home>dtTaskRep; 


CPUGS 
OO ABES H8 m Task CPU88...R 
66 0208:08023:80852F8FB 
2883918 "11 4 $1429: 111313141 
66 6268: 6663 : 6686866668 
^^5884tü #12 i J aga :! 88881 Bád 
ea 6006:06003:08681066 
^b a6b6C #5 a aago ess Mg 
66 600888:0009:0052F3FB 
CPUS81 
H2 h Task CPU81...5S 
8 8208:80888:8852F3FF 
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Figure 17. Process Monitoring - TaskRep 
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It is possible to end the process with the command Kill(<process>); . 


It often happens that a process calls another process as a helper with the Spawn() or PopUp() 
function. That helper is a child process, although we can call the process ourselves and assign it 
another parent, for example Adam. Links are kept as whose child is whose, so that when one 
process is terminated, the child process is also terminated. 


TempleOS uses the so-called "Master-Slave" approach. Core0 is the main core and has an Adam 
process, and as such is the master. Application cores can have Seth processes running and are 
known as slave processes. Only Core0 processes can have windows and run applications. Slave 
cores are used if the application explicitly calls a process or queues some job. 


5.2 Process scheduling 


The genius thing about scheduling processes inside the zero ring is that if we think a processor 
is busy because it's reported as busy it might actually just be waiting for I/O and it's stalled, so 
even though it has high utilization, it's just waiting for I/O. When it is waiting for I/O or disk, it 
reads the I/O port and then hands off to the next process with the Yield() function. This means 
that if we have a While (TRUE) Sleep(0) loop, the processor is tied and at full utilization but 
there is no performance problem because it immediately replaces with the next process[2]. The 
following image demonstrates this theory; context is being replaced over 4 million times per 
second (Figure 18). 
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Figure 18. Process scheduling 


The scheduler uses the round-robin method. Checks if the process is ready and executes it or 
skips it. Process swapping only involves saving and restoring registers (does not involve disk 
I/O or memory mapping changes). It is always mapped exactly identically on all cores. Processes 
can be switched in half a millisecond. 


The scheduler checks whether the task is waiting for a certain amount of time or waiting for a 
message and skips it if it is not ready. The process executes until it voluntarily relinquishes 
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control to a call to Yield(). Processes waiting for I/O often iterate, checking the status and calling 
Yield(). This does not degrade performance, but it puts a strain on the processor. 


6 Memory and process management 


What 1s distinctive about TempleOS when talking about memory mapping is that TempleOS 
does not use a virtual memory model. The mapping is extremely simple: virtual and physical 
address spaces are identically mapped, meaning that virtual addresses correspond to physical 
ones. The only things in the system that interfere with full access to the computer's RAM are 
the BIOS and memory-mapped devices. 


Physical memory 


| 1:0.99 correspondence | 


Virtual memory Uncached alias 


t Memory-mapped hardware 


Figure 19. Almost 1:1 mapping. Even address 0x0 is a valid memory location 


(https://minexew.github.io/2020/03/29/templeos-loader-part2.html) 


By default, memory access is cached. For hardware access, this is usually undesirable, so there 
is an uncached alias, which allows access to all memory locations but bypasses the cache 
cleanly. 


It should be noted that TempleOS only allows code to exist in the first 2 gigabytes of memory. 
The reason for this is to reduce the size of the binaries and to allow the use of 32-bit relative 
jumps everywhere. 


As already mentioned, paging is practically not used. 64-bit mode requires paging, so it is 
mapped identically. All processes on all cores use the same map of page tables, as if they were 
all physical addresses. 2MB or 1GB page table entries are used. Nothing is transferred to disk. 


In TempleOS, the lowest 2GB of memory is called the "code heap". The compiler always uses 
32-bit signed JMP and CALL instructions because 64-bit CALL instructions take up two 
instructions. With signed +/- 32-bit values , the code can only call the function within the 2GB 
range. Therefore, TempleOS stores the code itself in the lowest 2GB memory addresses, 
including the kernel. 


New, independent heaps can be created using HeapCtrlInit(), which can be used as the second 
argument to MAlloc(). 
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leaks. The MemRep() tool offers useful things for monitoring and managing memory (Figure 


mentioned Adam is a process that never dies. Its memory is like kernel memory in other 
Allocated memory is automatically freed when a process is killed, reducing the risk of memory 
20). 


Memory allocated by a process will be freed when the process terminates. The previously 
operating systems. 
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Figure 20. Memory monitoring with MemRep 
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6.1 Hash tables 


There is a hash table for each process. When a symbol cannot be found, the symbol table of the 
process's parent is checked. All processes lead back to the Adam process. Symbol tables within 
TempleOS are implemented as an array of linked lists (Figure 21). 


Figure 21. TempleOS hash table 


A number is generated from a string using the HashStr() function to index into an array of linked 
lists. Multiple strings can generate the same number, so linked lists are made. Newer entries 
override older ones. 


Symbol search is performed as follows: 
1. The symbol name is hashed by adding and shifting the ASCII values of all characters. 
2. Array is indexed using (Class) hash table->body[]. 
3. The linked list is searched until a match for the text and input type is found. 


4. If not found, the next table is searched using hash table->next. 


6.2 I/O operations 
TempleOS uses direct hardware access. 


Memory-mapped I/O (MMIO) allows direct access to hardware device registers via specific 
memory addresses. Physical addresses are directly mapped to hardware registers and allow 
read/write operations for direct hardware interaction. 


Port-mapped I/O (PMIO) uses specific CPU instructions to read and write to hardware ports 
("in" and "out"). These ports are specific I/O addresses that the CPU can directly access to 
communicate with hardware devices. 


The I/O space is unified with the memory space, which was already mentioned. For certain 
hardware communications, non-cached aliases are used to avoid stale data. 


Regarding I/O operations in code, TempleOS provides a set of standard functions for performing 
I/O operations. The FileRead and FileWrite functions enable direct and efficient I/O operations. 
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7 | Security 
In terms of security, TempleOS has a unique minimalist approach. 


There is no user authentication. There are no permissions and privileges, each process has full 
access to all resources. There is direct access to the hardware without layers of abstraction. 
These decisions raise a couple of security implications. 


The design philosophy of the TempleOS operating system prioritizes simplicity and ease of use 
over security, which leaves the system vulnerable to accidental or intentional abuse. 


In theory, TempleOS is highly vulnerable to malicious code. With no user separation, 
permissions, security framework, any code that is run has unrestricted access to the entire 
system. 


TempleOS intentionally lacks networking, which significantly reduces the possibilities of 
system attacks, but also reduces the functionality of the system in today's Internet age. Due to 
the lack of security mechanisms, TempleOS is not suitable for applications that require data 
integrity and confidentiality. 


Of course, the whole system is built on the basis of transparency and comprehensibility, and as 
such is intended more for educational purposes. 
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8 Testing environment 


The version of TempleOS that will be used is TempleOS 5.03, the last and final version of the 
operating system. 


TempleOS runs inside the VirtualBox operating system virtualization program, version 7.0.18. 


The specifications of the virtual machine are as follows (Figure 22): 


f Oracle VM VirtualBox Manager = oO x 
File Machine Help 


BI Toots OQ u >. 


New Add Settings Discard Start 


- E General = Preview 
Name: TempleOS 
Operating System: Other/Unknown (64-bit) 
= System 


TempleOS 


Base Memory: 4096 MB 

Processors: 2 

Boot Order: Floppy, Optical, Hard Disk 
Acceleration: Nested Paging, PAE/NX 
Œ Display 

Video Memory: 9 MB 


Graphics Controller: VBoxVGA 
Remote Desktop Server: Disabled 


Recording: Disabled 
A Storage 
Controller: IDE 
IDE Primary Device 0: TempleOS.vdi (Normal, 2.00 GB) 
(2 Audio 


Host Driver: Default 
Controller: | ICH AC97 


$? Network 

Adapter 1: PCnet-FAST III (NAT) 
© USB 

USB Controller: OHCI, EHCI 
Device Filters: 0 (0 active) 


O Shared folders 
None 


© Description 
None 


Figure 22. Environment specifications 
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8.1 System installation 


In order to be able to use the operating system smoothly in a virtual environment, we need to 
install it on a virtual disk. At the first launch, we will be presented with a user interface asking 
if we want to install the operating system on the disk (Figure 23). 


empleüU 


empled "n: 
Public Domain Operating System Public Domain Operating System 


ude "Once"; 


gou 'No' you can play with 
he live CD Mitho uk installi 


Figure 23. The first part of the installation 


There is also the question of whether it is installed on a virtual machine. After selecting the 
options, the system resets the disk on which the system will be installed, and copies the files to 


it (Figure 24). 
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Figure 24. The second part of the installation 


After installing the system, it is necessary to turn off the virtual machine, and detach the .iso file 
attached to it. This will allow the system to boot properly. After booting the machine a second 
time, a simple bootloader is displayed, with options for disk C and disk D (Figure 25). 
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iTempleOS Boot Loader 


9. Old Boot Record 
1. Drive C 
^. Drive D 


Figure 25. TempleOS bootloader 


Given that the system is installed on C, option 1 is selected. An identical view of the operating 
system is obtained as when booting from an optical disk, with the fact that it is now on the hard 
disk (Figure 26). 
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Figure 26. Installed TempleOS 
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9  Userinterface 


At the very start of the system, the option to go through the system is offered, which is 
imperative when starting to use the system because it makes the more or less unintuitive user 
interface a lot easier (Figure 27). 
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Figure 27. Tutorial 


Clicking on F1 opens a help window containing categorized and concise documentation (Figure 
28). 
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Figure 28. Help window 
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The following figure will explain the initial user interface (Figure 29). 
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Figure 29. User interface 


1. Status Bar — This part of the desktop lists things like the current screen refresh or 
processor core usage. 


2. Using files - When files are listed in the text window, they can be selected with the mouse 
or keyboard. 


3. Entertainment and Games — These icons are animated and clickable. The categories are 
divided into "fun games", "non-fun games", and "non-games" (various software). 


4. Shortcut Guide — This pop-up window serves as a quick guide to system functions using 
keyboard shortcuts. 


5. Windows - TempleOS supports multiple windows that can be moved in the familiar way, 
by dragging the title bar. 


6. "See more" - If the contents of the window are larger than the window itself, a "more" 
prompt will appear at the bottom of the window, indicating that the contents can be 
lowered with the mouse or keyboard[6]. 
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10 Development and maintenance 


With the death of Davis in 2018, active official development of this operating system was 
terminated. After his death, the TempleOS community focuses on preserving his work, archiving 
his videos, maintaining websites, repositories and forums dedicated to the operating system. 


TempleOS is open source, and its code is available for anyone to study, modify, and distribute. 
This allowed the community to continue to explore and experiment with the system. 


Chud's Vacation is a game created on the first TempleOS software rasterized 3D game engine. 
It was published on August 11, 2024, six years after Davis' death. (Figure 30). 
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Figure 30. Chud's Vacation main menu 


Terry Davis, along with his TempleOS operating system inspired the community to create their 
own forks of this operating system. The most famous currently active forks are ZealOS and 
TinkerOS. 
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ZealOS is a modernized fork of TempleOS. The main features are the existence of 32-bit VBE 
graphics, full support for AHCI, USB drivers, UEFI booting.. Some ofthe changes are 60 frames 
per second, ability to change resolution, added comments and documentation, reformatted code 
for readability, changed system-level names for comprehensibility (Figure 31). It is available on 
Github and can be downloaded from the  linkhttps://github.com/Zeal-Operating- 
System/ZealOS. 


Figure 31. ZealOS 


TinkerOS is essentially just a renamed TempleOS with minor tweaks to allow it to run on more 
modern machines. It supports AHCI, USB, 255 colors instead of 16... It is available on Github 
and can be downloaded from the linkhttps://github.com/tinkeros/TinkerOS. 
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11 Conclusion 


TempleOS is a unique operating system that stands as a testament to the power of individual 
vision and creativity in software development. TempleOS shows a unique combination of 
simplicity, efficiency and direct interaction with the user through its special features such as the 
programming language HolyC, the special file format DolDoc and the transparent and direct 
architecture. TempleOS challenges conventional notions of operating system design and 
emphasizes the values of minimalism and personal ingenuity. Although TempleOS may not find 
practical application in industry and other mainstream environments, its importance lies in its 
philosophical and educational contributions. It inspires developers to think creatively and 
explore alternative approaches to system design. TempleOS serves as an example that 
revolutionary ideas and products often arise from unconventional approaches, and as such 
encourages the technology community to appreciate different perspectives in operating system 
development. 
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